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THE SCOPE OF THE STUDY 



?f scribes two studies designed to investigate 

l - Y ? “ Sing 3 com P ute c to produce mathematical 
texts and musical scores in Braille, in IBM 709 computer 

for HV\ T* ln the P roaucti °n °f Braille literary material 
for several years. However, the rules which govern the 

distinction tn l ”f? : ! ,e,natlcal and musical material are quite 
stmct from the literary rules and reguire completely new 

programs to apply them. Furthermore, the problems of 
preparing mathematical and musical material in a 
machine-readable form are very complex. 

In the course of these investigations- the rules of thf 

MATHE MATICS ANJ) SCIENTIFIC NOTATION 
^r^Tr iQ^of 6 REVISED INTERNATIONAL .MANUAL OF BRAILLE 
MUSIC 1956 (2) were studied in great detail. Consultations 

vielded r ^nf nel V the flmerican Printing House for the Blind 
yielded information ab.out current production practices. 

^udies of representative mathematical and musical material, 
both mkpnnt and Braille versions, highlighted the nature 
of the input preparation problems. 



Both studies indicated the feasibility of automating the 
production of this material. The study of Braille 

)rogressed well into the development stage, 
was outlined and some sample subroutines 

\i * ‘ 



mathematics 
program plan 
detailed. 



A 



Time did net permit the study of Braille music to 
progress to that extent, but a very general plan was 

ana ^ discovery of a suitable input language 
notation^ 8 0003:1363:31)16 Problem of representing musical 



The authors conclude that computer programs can be written 
to produce Braille mathematics and music, and urge that the 
implementation of these programs begin a^ soon a! possible? 
1 e shortage of skilled transcribers is acute. Automating 
_che production of these specialized Braille codes will 
insure that the Braille reading population will continue to 

n^f ria ? \ h6J 11663 an3 Want for th6ir education?! 
and professional advancement. 
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BACKGROUND 



Braille is a system of raised dot representation which 
enables the blind person tc read using his sense of touch. 

The basic character is a six dot cell ( 11 ) and the 63 

0 

different characters are used, singly or in combination, to 
represent the total range of inkprint characters. Tills 
limited character set reguires .that each ceil be multiply 
used. The significance of the characters and the rules 
governing their use vary, depending on the material 
represented. Literary material is transcribed according to 
the rules of ENGLISH BRAILLE AMERICAN EDITION {3} while- 
music is written following the rules specified by the 
INTERNATIONAL MANUAL OF BRAILLE NOTATION. {2} The newest, 
most comprehensive system for mathematical material is the 
NEMETH CODE OF BRAILLE MATHEMATICS AND SCIENTIFIC 

NOTATION (1) currently undergoing revision prior to its 
final adoption. 

\ 

Each of these codes defines the character set* uniguely. For 
example, the Braille cell {dots 2, 3, 6) may be used 

for the word HIS in a literary text. Properly used in a 
mathematical expression it is the number 8, and in music if 
is the symbol fpr the staccato, a dot above or below a note. 
Within each code, a given Braille sign may have multiple 
meanings.^ The rules specify how these signs must be used to 
avoid ambiguity. The literary code uses the same sign to 
represent an opening guotaticn mark, a guestion mark, and 
the contracted representation of the word HIS. For this 
reason, the word HIS must be spelled in full if it is in 
contact with a. punctuation sign. The Nemeth Code, which 
uses, the same punctuation signs, reguires that a punctuation 
indicator be interposed between a number and a punctuation 
sign in order to distinguish the seguence 8? from 88. The 
rules of Braille music specify where the staccato symbol 
should be placed in relation to the note and other nuance 
symbols in order to insure clarity. 

Each of these codes further details how material must be 
arranged, how information can be abbreviated, or condensed, 
and how an, expression or phrase can be divided if it is too 
long to be accommodated on one line. In the case of 
mathematical and musical material, it is obvious that format 
rules are extremely important, since the relative position 
of a number or note influences its significance. Such rules 
are also an important part of the literary code, especially 
in the representation of poetry, letters, lists, tables, and 
other special forms. 
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The great bulk of Braille published uses the literary code. 
In addition to fiction, poetry, non-fiction and textbooks, 
it i also used to transcribe the expository portions of 
mathematics and music texts, and lyrics for vocal music. It 
was therefore the first to be programmed for computer 
translation. A growing shortage of skilled Braillists, and 
the difficult and lengthy process of training replacements 
gave rise to the development of a computer program for 
translating literary material to Braille. That first 
program, wr.itten by IBM in cooperation with the American 
Printing House for the Blind, converts literary texts, in 
punched card form, into Grade 2 Braille, and produces a.n 
output deck of cards containing the Braille codes as well as 
format control codes. This deck operates the 

“Controlled stereograp;. "iguipment which produces the 
zinc master plates used to emboss Braille. 

’k « 

The original program, written for the IBM 704, (4) and the 
subsequent version for the IBM 709 (5) currently used in 
production have been extensively documented elsewhere and 
will not be detailed here. Briefly the basic, unit of 
translation is a word, defined as a stream of characters 
between spaces. Ey reference to a highly specialized 
dictionary the program selects a tentative translation and 
then performs a series of tests to determine whether the 
Braille codes are correctly used. The program also arranges 
the Braille in the format reguired for the material being 
translated, supplies page numbers and titles, centers 
headings, etc. 

Since 1964 when an IBM 709 computer was installed at the 
American Printing House for the Blind the original program 
has . been considerably modified and expanded to handle a wide 
variety of material including textbooks which must be. 
formatted according to a special set of rules. The computer 
has been used to produce mere than 1000 Braille volumes. 

The success of the literary translation program and the 
continuing difficulties in hiring and training transcribers 
led naturally to a consideration of the specialized codes. 

In 1966 the study of the .Nemeth Code was undertaken to 
determine the feasibility cf writing a computer program to 
apply those rules. A similar study of the Music Code was 
started in 1968. Although the methods used in these two 
studies are similar and the conclusions identical, the codes 
themselves and the problems encountered are distinct enough 
to warrant individual discussion. Therefore, following a 
general description of the methodology, the details of the 
mathematics .and music studies are described separately. 
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METHODOLOGY 



Determining whether any human activity can be performed by a 
computer reguires a thorough analysis of the activity 
itself, as well as the nature of the data to be handled 
(mp.ut) and the form of the results (output) . Although the 
study of these three aspects of the problem may be 
concurrent, the logical starting place is the processing 
which must be performed by .the computer. The rules and 
practices which govern the manual activity must be examined 
to determine whether they can be codified for computer 
handling.. Where there is a reliance on individual judgment 
for certain decisions, the attempt must be made to specify 
the basis on. which such judgments are made. 

Assuming that a preliminary investigation indicates that a 
com.put.er can be programmed to make the necessary decisions, 
the problems of input and output must then be considered. 

If the i.nput data does not already exist in a machine 
readable form it is^ necessary to develop a method for 
converting it*. Similarly the computer produced output may 
have to he processed further to produce the desired results. 

The input for any Braille translation program is printed 
material which, at present* must be copied by a keypunch 
operator. Future developments in; optical scanning devices 
and the use of typesetter tapes may one day obviate this 
step but it is currently the most, practical procedure. The 
problems of input preparation for Braille mathematics and 
music are similar to, but far more complex than; those of 
literary Braille. The input language developed for the 
?^ er ? r y Program specifies some special codes to represent 
mkpnnt characters not found on the keypunch keyboard and 
to indicate paragraph beginnings, chapter titles, and other 
characteristics of the printed material which can be 
represented in Braille. 

• 

Mathematical material, while utilizing the basic alphabetic 
ana numeric character set, aiso includes numerous symbols 
for which there is no keypunch equivalent .and the special 
formats are many and varied. One philosophy underlying! the 
Nemeth Codecs that the Braille representation be arranged 
as nearly like the inkprint. as possible. It is therefore 
very important that the format of the printed material be 
completely and accurately indicated^. 

Musical material poses an even greater problem since almost 
none of the symbols are found on the keyboard, and the 
location of a given symbol, which is integral to its 
significance, may vary widely. 



T1 



The essential requirements for an input language for 
mathematics or music, or any other special material, are 
that it be unambiguous and easy for an average keypunch 
operator to learn and use. The object in using a computer 

production is to utilize the readily achieved 
skill of keypunching instead of the very complex decision 
ma ing required of a highly trained Braille transcriber. To 
reguire that the keypuncher be well versed in mathematics or 
music or Braille would negate the purpose of using the 
computer. An additional consideration in designing such a 
xanguage is to minimize the number of keystrokes required to 
represent a given inkprint symbol and to select codes which, 
whereve. possible, have some mnemonic significance.. 



The third aspect .of the problem, that of output, is the one 
vhich required no additional development. Output from any 
specialized Braille program can be in the same binary card 
f k orm currently used to control the stereograph equipment. 

One further comment about methods is pertinent here. The 
depth of analysis and the developmental work, if any, will 
vary depending, upon the nature of the problem,, the amount of 
-ime allotted, and the kind of answer being sought. The two 
studies described here were designed to establish the 
feasibility of writing computer programs for these 
specialized Braille codes. Curso.ry- study indicated that 
such programs are possible; the detail employed here is 
necessary to show that they are practicable. 



The study of Braille mathematics occupied a major portion of 
the grant period, and progressed beyond, a feasibility study 
into the design and partial implementation .of an actual 
program. Further progress in that direction was 
interrupted, not only because the Nemeth Code was undergoing 
revision, but also to allow, time to investigate the problems 
of Biaille music. Although a relatively short time was 
spent in that study, two factors favorably influenced the 
amount of progress that was made. The formidable task of 
developing an input language for musical notation had 
already been accomplished as part ,of a project to automate 
music typesetting. The time spent studying that language to 
insure its suitability was but a small fraction of the time 
required to develop it. Ia addition, some of the problems 
of formatting music .are analogous to those in mathematics 
and can be implemented using techniques similar to those 
developed during that study*. 
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BRAILLE MATHEMATICS 



Because mathematical texts contain both expository and 
mathematical material, the rules of the NEMETH CODE OF 
BRAILLE MATHEMATICS AND SCIENTIFIC NOTATION (1) were studied 
as a unit, and in relation to the rules of ENGLISH BRAILLE 
AMERICAN EDITION. (3) It was clear at the outset that any 
program for mathematical expressions would have to be 
coordinated with the existing literary program. It was also 
clear that the combined program should determine whether a 
given stream of input characters should be translated by the 
mathematical or literary portion of the program. Such a 
decision should not be required of the Keypunch operator. 
These considerations were of prime importance in the early 
study of the problem.. 

A detailed review of the rules of Braille mathematics began 
first with many read.ings of the Nemeth Code and constant 
references to the rules of English Braille. The authors* 
familiarity with t-hat latter, code was guite valuable here. 
The Introduction to the Nemeth Code states that, in 
transcribing technical works, "the rules or English Braille 
and of the Nemeth Code will be rigidly followed within their 
respective domains. *' For the sighted transcriber, the 
boundaries of these domains are obvious from context. For 
computer interpretation, however, these must be defined in 
highly specific terms. Numeric information is, of course, 
easily identified. However., such alphabetic sequences as 
SIN x and COSH y are also mathematical expressions and must 
be transcribed according to the rules of the Nemeth Code, 
not English Braille. Identifying a mathematical expression 
is necessary to insure its correct transcription as well as 
the correct form of adjacent literary material. (e. g.. 
Contractions for TO, INTO and BY must not be used before any 
mathematical expression.) 

Deciding whether a computer could distinguish a mathematical 
expression was a necessary first step in the feasibility 
study. To this end, a representative selection of 
mathematical texts was reviewed to insure that an algorithm 
could be developed to handle the various forms of 
expressions. After considerable study, a general strategy 
was designed to satisfy the requirements discussed above: 
that the. mathematical and literary programs be coordinated; 
and, that the computer be programmed to distinguish between 
these two domains. 

« » i 

The mathematics program tfas designed as a pre-processing 
routine which scans all input data before transmitting it to 
the existing Braille translation program. It performs no 
translation into Braille. Instead, it utilizes a small 
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dictionary and a few analytic routines to distinguish 
mathematical expressions from expository text. The literary 
material is passed unchanged to the literary program to be 
translated according to the rules of English Braille. The 
mathematical material is modified by fhe addition of special 
codes which will cause the translation program to supply the 
appropriate Eraille. The modification may be simp.ly the 
insertion of special codes around the expression SIN x or 
the very complex adjustments necessary to format exercise 
arrays, computation examples, complex eguations and the 
like. The existing program utilizes an expanded dictionary 
to perform all of the translation to Braille. This is 
especially desirable since the line arrangement and 
pagination functions are embedded in the present program. 

To separate the translation of the two types of material 
would involve unneccessary duplication.. 

In this kind of study, the analysis of the problem and the 
development of solutions are concurrent and interactive 
processes. While, detailed solutions were not considered 
until later in the study period, the over-all design and. 
some specific techniques were being developed as each new 
aspect of the Nemeth Code was studied. 

Once the basic structure of the pre- processor was outlined, 
attention was focussed on the not inconsiderable problem of 
format. Dr. Nemeth states .that M the> Code is intended to 
convey as accurate an impression as is. possible to the 
Braille reader of the corresponding printed text.” (6) it 
is therefore necessary to supply as input to the computer an 
accurate description of the content and the arrangement of 
the printed page. The description should be in terms which 
reguire no specialized mathematical training and require as 
few .keystrokes as possible. 

Developing this input language required studying, not only 
the rules of the Nemeth Code, but also the practices 
currently used to transcribe mathematical texts. Because 
elementary school texts are an important segment of the 
mathematical Braille produced at the Printing House, 
attention was directed to the format problems found there. 

It is interesting to note that, because of the introductory 
nature of these books, there are more unusual spatial 
arrangements than would be encountered in higher le 
texts. With the help of the Mathematics Editor, Mr. Balph 
McCracken, a representative group of texts was selected for 
study 6 These were books which included examples of 
•conventional* as well as *new math* presentations. Because 
they had already been transcribed manually, the inkprint 
copy which had been annotated by the editor and the Braille 
edition were both available. 



In the course of studying this material, a general plan for 
an input language was developed and specific codes and 
statements were designed. The assignment of special codes 
to represent characters not on the keyboard was based 
primarily on considerations such as mnemonic value and 
keying ease. The programming reguired to translate these is 
trivial. However, the choice of format statements was 
influenced by programming considerations as well as ease of 
use. 



In. general, the more information supplied by the keypunch 
operator, the less work reguired of the computer. Consider, 
for example, a set of addition exercises shown in print as 
follows : 

a , b c 



1 . 



15 

3 



10 

. 12 



6 

2 



2. 22 5 17 

,11 -9 21 

In Braille, the arrangement of the exercises should be the 
same if space permits. However, the column designation (a, 
b, c) is shown next to each exercise, followed by a period, 
the separation lines are extended, the problems must be 
separated by two spaces, .the column and row designations by 
two spaces, etc. The keypunch operator could be asked to 
key the column headings apprcpriatel-y , and to supply the 
spaces as reguired by the Braille rules. The computer would 
select the Braille codes and supply numeric, and punctuation 
indicators as reguired. However, such an approach reguires 
of the keypunch operator almost as much work as is performed 
by the Braillist and would make the use of the computer 
impracticable. 



In order to minimize the work reguired of the keypunch 
operator, a simple descriptive statement was designed. The 
work of rearranging, inserting periods, counting spaces, 
aligning exercises is performed by the computer. The 
exercise array shown above is described as follows: 



XFORH 2 rows (1.-2.) 3 cols (a-c) 

Each example is then punched as a unit including the 
separation line. (e. g., 15,3// 10,12// 6,2// etc.) The 
XFORM statement provides the information needed for the 
computer to arrange the exercises properly. 
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Each statement was designed to meet two requirements; to 
provide all the necessary information to the computer; and, 
to minimize the work and special knowledge required of the 
keypunch operator. It was then tested by several operators 
at the Printing House who keypunched specified portions of a 
text. The results of these tests and the operators* 
comments provided a basis for modifying th,e statement where 
necessary, or for expanding the instructions about its use. 
Some examples of these statements and instructions are found 
in Appendix A, as well as a flow chart and detailed 
description of a routine tc implement the XFOBM statement. 

The set of statements which were designed and tested during 
this study is by no means a complete input language for all 
mathematical material. It is probably sufficient for most 
elementary school texts c However, the program has been 
designed to facilitate the addition of subroutines to handle 
new format statements as they become necessary. 

This section describes the major problems which had to be 
solved to demonstrate the feasibility of writing a program 
to produce Braille mathematics. The methods of studying 
these problems and some proposed solutions have also been 
described in general terms. A detailed discussion of these 
a k nd many other aspects of th,e Nemeth Code and the proposed 
program is found in Appendix A. 

Because of the depth of this study, ,the findings can be 
stated very positively. A program has been designed which 
demonstrates that a pre-processor can be linked with the 
existing Braille pro.gram in use at the American Printing 
House. It can distinguish mathematical expressions, supply 
the many new indicators required by the Nemeth Code, insure 
the appropriate use of contraction codes - within or in 
contact with mathematical expressions, and can make use of a 
minimum amount of information about format to .produce 
properly arranged Braille. Although the present design was 
intended to work with the existing 709 program, the validity 
of the. feasibility statement is not dependent upon ^either 
the compr+er or the program. It has be«n demonstrated that 
the rules of. the Nemeth Code are ’computable* and that 
complex spatial arrangements can be described using a set of 
fairly simple statements. 



BRAILLE MUSIC 
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As was true for the study of Eraille mathematics, the two 
major problem areas considered during this study of Eraille 
music were the preparation of input, and the processing 
reguired of the computer, however, the nature of the 
problems vary in degree and kind. The difference in the 
input preparation problems is obvious. Describing musical 
notation using a keypunch requires an extensive input 
language much lai;ger than the set of input statements and 
codes reguired for mathematical material. There is very 
little coincidence between inkprint music symbols and the 
character set of the keypunch. Only lyrics, tine signatures 
and other numbers can be transcribed directly.. 

The second major difference is exemplified by the following 
quotes: 



”The rules of the code are intended to reguire a 
minimum of decision making and interpretation on 
. the part of the transcriber... the transcriber is 
reguired to represent the sign and to be 
unconcerned abo.ut the meaning of that sign.” 

NEMETH CODE OF BRAILLE MATHEMATICS (6) 

"This book has been written for the use of seeing 
musicians who wish to learn the system of Braille 
music notation in order to transcribe -inkprint 
music into Eraille.... The student should have a 
complete knowledge of the rudiments of inkprint 
staff notation, together with special facility in 
whatever type of music interests him as a- 
transcriber 

LESSONS IN BRAILLE MUSIC (7) 

> 

A further aspect of the difference between the two. codes is 
the degree of choice permitted the transcriber. Dr. Nemeth 
specifically directs that the rules be followed literally 
and enjoins the transcriber against making .any - 
modifications. In contrast, the INTERNATIONAL MANUAL OF 
BRAILLE MUSIC, a compilation of decisions reached at the 
1954 Paris Conference, strives to strike a balance between 
"rigid regimentation of rules and an easy acceptance of 
alternatives. 51 (8) The latitude .permitted by the Code, and 
the musical knowledge required of the transcriber appear, at 
first 9 to be serious obstacles to the use of a computer to 
produce Braille music. However, closer examination revealed 
that a computer can be programmed to handle much of the 
decision making currently required of the transcriber. 



The musician-transcriber, familiar with inkprint staff 
follows?* rec °9mzes that a note represented in inkprint as 
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i 
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is an F sharp, dotted guarter note. For purposes of Braille 
ranscription it, must also be .noted that the note is in the 
fourth octave.. This is an objective decision based on the 
fu ^?d shape of the note, its location on a staff, and 
the definition of the staff as indicated by the clef sign. 
Given these same data a computer can be programmed to- 
identify the note. 



The problem is to develop a means of describing all tnese 
objective characteristics of a given musical symbol. The 
language should be easy to learn and apply, and should 
reguire no special musical training. The number and variety 
of musical symbols is such that developing such a languaqe 
is a major task. During the period of this study the 
authors could have made only a small contribution. 
Fortunately, such a language had already been developed as 
part of a project to automate musical typesetting. Mr 
Stefan Bauer-Mengelberg and his colleagues, working under a 
Ford Foundation grant, spent nearly three years designing 
and testing a method of keypunching musical notation. 

Mr. Bauer-Mengelberg not only made this language available, 
but served as consultant to the study. The language uses 
symbols, wherever possible, which have mnemonic 
significance. The duration of a note, indicated by its 
shape and color, is indicated by a single alphabetic 
character. Its location is described by a one- or two-diqit 
number which refers to the line or space on which it 
appears. The lines and spaces of the 6 clef staff are 
numbered 20 - 29. Because these notes are so frequently 
used, the language permits the abbreviation of these codes 
by eliminating the 2. Each note, then, is described in 
terms of its location and shape. Other symbols which 
influence its musical significance, accidentals, 
articulation symbols, etc., are punched in prescribed 
seg.uence adjacent to the basic description. The note shown 
m the example would be punched: 



The motivation for automating musical typesetting and 
musical Braille are remarkably coincident. Both projects 
were undertaken because of the growing shortage of highly 
skilled technicians - typesetters and Braillists. Because 
this language was designed to represent the printed page 
with great accuracy, it can serve perfectly as input to a 
Eraille translation program, thus eliminating the need for 
the knowledge of musical notation now required. - 

However, the other major problem is the freedom accorded the 
transcriber to choose among alternate methods of 
representing a particular passage. The most obvious example 
is the choice of three methods of presenting keyboard music 
- bar over bar, line over line, and section by section* 
According to LESSONS IN ERAILLE MUSIC, "the layout is really 
very much the same in all three." However, this manual 

discusses "the rival claims of each of these systems in 

order to help the student in -making a suitable choice of 
disposition to suit different types cf music." (9) Here the 
transcriber is basing a decision on musical judgment and 
personal opinion, about what will simplify the task of the 
Eraille reader, s.uch judgments, net based on objective 
criteria, are often made differently by two transcribers. 

No computer can be programmed to make such judgments. . 
However, two solutions are possible. Whichever presentation 
is chosen, the resultant Eraille music is correct and 
complete. The choice exists because an agreement on one of 
these methods could not be reached at the 1954 International 
Conference on Braille- Music. One solution is to adopt one 
of these methods as the standard to be used for all computer 
produced Braille music. The , program would always present 
keyboard music in the same format. An alternate plan would 
require an editorial decision about each piece of keyboard 
music. ^ The computer would be programmed to apply the method 
specified. Even .though this requires some manual 
intervention, the monumental task of transcribing and 
arranging the Braille is assigned to the computer. 

Some other choice points faced by the transcriber have to do 
with adding to or subtracting from the inkprint 
representation. Such modifications are made to clarify the 
music for the Braille reader, to simplify the task of 
memorization and to cut down on the bulk of the finished 
work. For example, the transcriber may on occasion add 
rests, accidentals, or other symbols whose meaning is 
inferred by the sighted musician because his eye can take in 
several staves at once. For the Eraille reader, 
concentrating on one staff at a time, adding these symbols 
is important. 



The transcriber can also eliminate certain note sequences by 
the judicious use of repeat signs. There are many rules and 
restrictions concerning the use of these repeat signs and 
most of them can be stated in a form su-itable for computer 
application. In some cases, there is a choice among several 
methods of presentation which is left to the individual 
transcribers judgment. Especially with regard to the use 
of the part-measure repeat „ its use is a "never-ending 
study, and even among experts opinions vary very much in 
detail.” (10) This problem is analogous to the choice of 
score disposition discussed earlier and the same set of 
solutions are clearly applicable. 

Altho.ugh time did not permit the program design and 
development which was part of the study of Braille 
mathematics, the findings of this study of Braille music can 
be s.tated just as positively. The task of developing an 
input language is a major one - and has already been solved. 
Despite the leeway currently permitted the transcriber, it 
is clearly possible, and perhaps desirable, to make certain 
arbitrary decisions which can be programmed. Complex music 
will undoubtedly reguire editorial review, but the 
annotation required rill be far less than that of the 
sometimes extensive rewriting required for mathematical 
texts. . 

• % 

Finally, the great variety of inkprint music, while it 
requires extensive programming, can be segmented in. a way to 
facilitate the building of a complete program. The program 
can be designed in such a way that sub-sections to handle 
different musical forms can be added gradually. Monophonic 
music can be implemented first, then .simple polyphonic 
forms, and the program can. be progressively elaborated to 
handle more complex music and such special forms as music 
for plucked instruments, accordion, etc. This would he 
analogous to building the shell of a house, and then 
completing one room at a time. Such a design insures some 
utility at the earliest possible date, and provides a means 
for expanding the system without disturbing the already 
completed parts. 



20 




CONCLUSIONS 



The studies of Braille mathematics and music hc.ve shown that 
the rules of each code can be applied by .a computer program 
with a minimum of editorial intervention. . The problems of 
describing the content and arrangement of the printed page 
have been investigated and solutions have been developed. 

It is clear from these studies that computer programs can be 
written to produce both Braille music and mathematics which 
will conform to the quality standards of the American 
Printing louse for the .Blind. 

In light of the growing shortage of skilled transcribers, 
and the continuing and expanding oieeds of the Braille 
reading population, the conclusions drawn here should not be 
treated academically* Implementing such programs is a 
lengthy procedure and the completed programs must be tested 
on a wide variety of material. Experience with the literary 
program has demonstrated this, and has also demonstrated the 
value of using a computer for Braille, production. It is the 
authors' observation that the skill required for 
transcribing music is more complex ar,d in shorter supply - 
than that reguired. for producing elementary mathematics 
texts. If this is so, the music program should be 
undertaken first. 

Which program should be imp Lemented first, or whether they 
should be undertaken simultaneously is, of course, an 
administrative decision. Because of the time and skill . 
reguired to produce a working program, it is the authors' 
recommendation that a decision be made at the earliest 
opportunity, and that implementation be started before the 
shortage of transcribers becomes a lack of transcribers. 
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BLIND (BL) may not be used in the word BLINDED, since it 
would be misread as BLED, 

In addition to rules about how. words should be transcribed, 
there are carefully specified format conventions.' -They 
govern the size of pages, page numbering, paragraphing, the 
arrangement of chapter headings, the spacing of poetry, etc. 

The rules of English Braille are. used for transcribing 
literary, non-technicai material - whether it is 
accomplished manually, or by the 709 computer program. Some 
of the techniques used by that program to apply these rules 
are described in the succeeding section. 

The Nemeth Code of Braille Mathematics specifies how 
mathematical and scientific notation is to be represented. 
Since all textbooks contain some expository sections, the 
Nemeth Code is used in conjunction with the rules of English 
Braille. . In general, these rules must be us,ed in 
transcribing the literary portions of the text. The 
exceptions are specified by the Nemeth Code. 

While it uses the English Braille code assignments for 
letters and punctuation, the Nemeth Code introduces a new 
set of codes for numerals, additional indicator codes, and 
of course, new code combinations to represent mathematical 
symbols not found in literary texts. Numerals are 
represented by codes a through d in the lower part of the 
cell. Thus the letter B is still dots 1 and 2 but the 
number 2 is dots 2 and 3. The rules for the use of the 
alphabetic indicator are changed because there is no longer 
any confusion between the letters and. the numerals. However 
the lower cell numerical codes can be confused with some of 
the punctuation symbols. For example, the lower cell B 
(number 2) is the semi-colon. For this reason a punctuation 
indicator is specified by the Nemeth Code, to be used when 
certain punctuation signs are associated with mathematical 
expressions. The Nemeth 4, for instance, is the same code 
as the period. Therefore the seguence 123. reguires the 
punctuation indicator preceeding the period to distinguish 
it from the seguence 1234. The numeric indicator is still 
necessary because the lower cell Nemeth numerals can be 
confused with certain whole word contractions specified by 
English Braille. Consider the sentence * There were 7 

balls*. The Braille code ## stands for the whole word 

# 0 

contraction for *were' as well as the Nemeth 7. 

The Nemeth Code restrictions on the use of contractions are 
also based on the multiple meanings of the lower cell 
symbols. The Nemeth rules state that the contractions for 
*to, into and by* may not be used before a mathematical 



expression. The reason for this becomes obvious when one 
realizes that the contraction for ’.to* is the same as the 
Nemeth 6. Permitting the use of the contraction in such 
cases would lead to confusion. Similarly *into* might be 
read 96 - 'by 1 as 0. 

-The introduction of new Eraille symbols for certain 
punctuation signs is again based on the possibility of 
confusion with the numerals. The literary Braille symbol 
for the parenthesis is the Nemeth numeral 7 and the literary 
comma is the Nemeth 1. To avoid such reading problems the 
Nemeth Cede includes new symbols for the mathematical comma, 
mathematical parentheses, brackets, etc. 

Other aspects of the Nemeth Code are independent of the 
li.terary code and are based solely on the nature of the 
mathematical material as presented in inkprint. The Code 
specifies new symbols and combinations to represent such 
signs as arrows, comparison signs, logical symbols, and so 
on, which do not occur in literary texts. There are also 
new indicators introduced to facilitate reading 
comprehension. The fraction indicator provides a signal to 
the reader that the succeeding material is arranged above 
and below a fraction line and influences his method of 
scanning the following codes. 

An important philosophy .underlies the large segment of the 
Nemeth Code dealing with spatially arranged material. The 
attempt is to make the Braille presentation as equivalent to 
the inkprint as possible. The number and variety of the 
rules are quite extensive. Some of these are discussed in 
the following sections. 
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B. THE ROLE OF THE COMPUTER 



The several categories of English Braille rules are 
implemented by the computer program using two primary 
techniques: a detailed scan of .the input word and 

comparison of adjacent characters or bites; and, reference 
to a stored dictionary to locate whole words, or parts of 
words. There are two types of entries in the dictionary. 

The first o.f these governs the use of contractions and 
supplies the appropriate Braille codes for output. A 
smaller group of entries is used to arrange the Braille 
codes in the desired format. These entries contain 
’pseudo-codes' which are analysed by the program and 
converted to spaces, line endings, page endings*, etc. where 
necessary. 

Since textbooks contain both literary and mathematical 
material, they must be converted to Braille according to the 
rules of English Braille as well as -the rules of the Nemeth 
Code. Where there are discrepancies, it must be determined 
which set of rules should be -followed. Just as a skilled 
Braillist must ’know’ both sets of rules, so must the 
co.mp.uter program be able to apply both properly. * 

In order to achieve this, the existing literary. Braille 
program, with an expanded table, will be utilized as* the 
Translator. Input to the Translator will be provided by the 
Math Pre-processor which will, scan keypunched input, 
determine which set of rules should be followed, and wiil 
provide appropriate signals to the Translator. » 

The expanded table in the Translator program will 
accommodate tbs enlarged code set specified by the Nemeth 
Code and .will include entries which govern the translation 
of pseudo-codes supplied by the Pre-processor. This table, 
and the code set, is described in detail in Section D. With 
that .exception, this document describes the structure anti 
function of the Math Pre-processor. 

Keypunched input to the Pre-processor is analysed by the 
program to determine whether it ,rs literary or mathematical. 
Depending on the nature of the material, the Preprocessor 
will function in one of three different ways: 

1. If the word is literary, the input codes will be 
moved to the input list used by the Translator. 

The program has been designed to make this 
identification as guickly as possible in order to 
speed translation. 
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2. Mathematical material will fce analysed to determine 
whether additional codes are required and whether 
the input codes must be converted. This analysis 
is performed by reference to a table of significant 
mathematical words, or by a detailed scan of a 
sequence of codes which includes some mathematical 
symbol. The stream of characters which is then 
passed to the Translator is an expanded and 
converted version of the original input. 

3. When a Format code is encountered, the usual 
word-for-word transmission from the Pre-processor 
to the Translator is interrupted. .Th‘e 

. Pre-processor wil.1 continue to collect input words 
until the appropriate terminating code is read. 

When the intervening material has been arranged, by 
inserting line-ending codes and spaces, the 
Pre-processor will pass it, one word at a .time, to 
the Translator. 

The techniques used by the Pre-processor to apply the rules 
of the Nemeth Code are similar to those' used by the 
Translator. . There is a difference in emphasis, of course, 
determined by the differences between the literary and the 
Nemeth Codes. For example, the Translator performs a 
bite-by-bite scan to determine whether a given contraction 
may be used, or whether one of two indicators (numeric, 
alphabetic) should be inserted. The scan performed- by the 
Pre-processor also determines whether an indicator is 
required, but the larger set of indicators specified by the 
Nemeth Code means that there are more insertion routines and 
they will be used more frequently. The second function of 
the scan is to chose between the mathematical or literary 
representation of certain ambiguous inkprint signs. In 
certain of these cases, -the comparison of adjacent- 
characters may not provide definitive information and the 
Pre-processor will extend the scan to succeeding words. 

Some of the Nemeth Code rules governing the non-use of 
comcractions are implemented by -using a table. Unlike the 
.Translator’s Grade II Table, which is contrection oriented, 
the Pre-processor's Word Table defines a sms 1 group of 
words which cannot be contracted. Both tables include 
special format codes supplied by the keypunch operators. 

The difference in the metho.d of processing these codes is 
detexmined by the wide variety of spatial arrangements used 
for mathematical material in contrast to the more limited 
arrangements permitted for literary material. Therefore, 
associated with each format input- code is a subroutine which 
will accomplish the specified arrangement. 
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The Math Braille Translation Program is a single program, . 
although the Pre-processor and the Translator are described 
separately in this document. The succeeding Sections 
describe in further detail the tables and routines used -by 
the Pre-processor to supply the Translator with information 
necessary to produce a properly coded mathematical textbook. 



C. THE MATH PBE-PBCCESSOR 

The attached flow charts illustrate the general plan of the 

fn^»+ r ^ Ce f?° r m Pr ° 9 ? aiD ’ Output from this program becomes 
input to the Translator, which performs the conversi-on to 
Brailie* when the input has been identified as literary, 

the Pre processor passes the original input codes to the 
Translator • 

In handling mathematical material, the Pre-processor may 
either insert indicator codes, and/or, convert the input 
codes to a pseudo-code form which will influence the Braille 
translation. For example, the input code 22 g represents the 

letter 'B', which is converted to Braille dots 1-2 by th^ 
Translator, according to the rules of English Braille, this 
letter, standing alone, must be preceded by the alphabetic 
indicator to distinguish it from the word *BUT f . if the 

contact with a numeral, it must be preceded by 
the indicator to distinguish it from the numeral *2*. Y 

Sl nce the Nemeth Code numerals are represented by lower cell 
codes, there can be no confusion between *2* and *E f and 
the indicator is not reguired. Similarly, the indicator is 
not reguired m the statement *a b + c« . Therefore, when a 
single letter occurs in a mathematical statement, it is 
converted to a pseudo-code (B-122g) which produces the 



correct Braille code and prevents the 
alphabetic indicator. 



insertion of the 



The following examples will serve to amplify the flow 
charts. They illustrate how the program handles alphabetic 
material which is literary, alphabetical material which is 
mathematical, punctuation and numerical input. 



Example 1: 



Divide 400 by 2. 



The 



input codes for the first word in this sentence are: 



r divide 

|* he = * s . tb ® symbol for the capitalization indicator 
supplied by the keypunch operator.) The analytic scan 
performed by the Pre-processor finds that there is no 
mathematical symbol here, but that there is at least one 
non-alphabetic character. The program then follows the ' 
steps outlined under ALPHA and PUNCT. P-SCAN strips off 
indicators and punctuation so that the alphabetic characters 
alone may be examined. Since this word is not found in the"' 
Table, it is passed directly to the Translator, 
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400 



The next character stream. 



follows the SOME MATH branch of the program. The function 
of M-SCAN is to determine the need for insertion of 
indicators or the selection of the -mathematical symbol for 
certain ambiguous punctuation signs. In this case, M-SCAN 
supplies the pseudo-codes which produce the Nemeth Braille 
numerals, and which will cause x tbe Translator to insert the 
numeric indicator: at the beginning of the sequence. 

The word. 



by 



is located in the Special 3ord Table, and is placed in the 
HOID stack, pending the analysis of succeeding input. 

« i 

The final sequence. 



2 . 



is processed by M-SCAN, which supplies to pseudo-code for 
*2* and inserts the punctuation indicator in front of the 
period. t 

% 

The next step, setting the Grade I switch, is accomplished 
by passing the codes. 



$IG 1 

to the Translator. Until its effect is terminated by the 
codes $TG1 , this causes the Translator to use only the Grade 
I Table, thus avoiding the use of contractions. 

Since the HOID stack is not empty, the OUTPUT routine puts 
out: 

by 102| 

{102 Nemeth 2; | = punctuation indicator) 

Because the Grade I switch is on, the lower cell contraction 
for *by* will not be used. Had the seguence been 'by land’, 
the Grade I switch would not be turned on, and the 
contraction would be used. 

Example 2: 



(sin x) 
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The first set of codes. 



(sin 



wri i“ Mit P j ^ a " d ' after P-SCAN ' the unpunctuated 
"?£ d - f°5 a ^ ed ln the Special Hord Table. Since an 

I,** 6 * function name is a mathematical expression, and 

bv theVsMiJ ™ P «°^ rlY - the Sntire sequence is ana-lysed 
?7 * , The Hath-Switch setting causes B-SCAN to 

jj 0 t P detaifpfl S fn^°n C °e? f -° r . the mathematical parenthesis. 

Mot detailed in rhe flow chart is that f-act that, when an 

nmn Rouping symbol is read, M-SCAIi will place words in the 

acl an ? continue to fetch input until the matching 
closing symbol is read. y 

Therefore, M— SCAN reads the next seguence, 

x) 



i 

and selects the appropriate mathematical code for the 
parenthesis. in addition, it converts the * x* code to the 
form which will prevent the insertion of ?he alphabetic 
indicator by the Translator. The Grade I code which 
precedes the entire sequence .prevents the use of the 
contraction in the word »sin» 



m 



is 



Since much of the material in mathematical textbooks 
literary, the program has been designed to identify 

£^no? e ^ al al P habetic input quickly , in order to speed 
sla ti°n process. The pre-processing required for 
mathematical sequences is offset by the, use of the Grade I 
Table to translate these - a relatively fast procedure. 



the 



The tables and routines named here are described 
detail in the succeeding sections. 



in further 



GENERAL FLOW CHART - MATH PRE-PROCESSOR 



V . | 1 . V 

| 1 . j BEAR INPUT -WORD - | . | j 

1 SOME MATH j . | 1 . | ALPHA AND PUNCTj 

I 1 . - - - - . | 1 



V . . V 

I J . I 1 

j M - SCAN I V j SET P SNITCH ON| 

j | | j | , 

.... | . .A.LL ALPHA | 

V v I —| V 

1 - . | | 

SET G1 J | P - SCAN | 

j SWITCH CN I V . V | 1 

1 XXXXXXXXXXX 

• ----- X X 

V . X SPECIAL.? X (N) 

j ...... .x. ..... 'X • 

| OUTPUT I XXXXXXXXXXX V 

| | | | 

j OUTPUT J 

j , 

(-*) 



• • 

V V 

, J I 1 

| AEBREV FUNCT. .NJLM.EI .|..TO, INTO, BY | 

1 } ARC | 

. . ! — 1 

V . 

XXXXXXXX V 

X - x 1 1 

u . (N) .X P SWITCH X.. I PUT IN HOLD | 

X ON?. X . I STACK 1 

XXXXXXXX V | | 

(X) 

- V 

V READ 



j , 

j SET MATH SWITCH ONj 

| | 



V 

| j 

| FORMAT CODE 1 



V 



, 1 

j FORMAT ROUTINE j 
| 1 



, j 

j OUTPUT 1 
j j 



1 

I 

I 



M - SCAN 



-I 
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OUTPUT SUBROUTINE 






| TEST -H-GLD- ST ACK- -j- - 
| | 



XXXXXXXX 

% -X - 

X EMPTY? x. 
IX --- X- 
XXXXXXX.X 



(N) 

V 



V 

(X) 



OUTPUT 
HOLD 
STACK- - 






1 



OUTPUT. | 
WORD . | 



1 



xxxxxxxxx 

X- -G RA DE -1 -X - - 
X SWJTCH . X. ... (N) 
X ON? X 

-x-x x-x-x-x-x-x-x --- 



-V 

m 



V 



| TURN OFF 1 
i SWITCH | 

| j 



V V 
RETURN 






NOTE: WHEN CALLED BY FORMAT ROUTINES', -RETURN -IS- TO- THE 
FORMAT ROUTINE UNTIL LAST WORD IS OUTPUT; THEN, TO READ 
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ERIC 



5 



j 



3 

% 



Z 



Jg 

Z 



I 



2 



$ 



3 






s 



s 

3 



* 



s 



X 



% 



'i 



% 
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D. TABLES 



The Math Translation System , makes use of three tables to 
apply the rules of the Nemeth Code. Two of these are used 
directly by the Pre-processor and will be referred to as the 
Symbol Table and the Word Table.. The third is an expanded 
Grade I Table which is part of the Translator program. 

Expanded jGrade I Table 

The original Grade I Table was designed to translate all the 
valid input characters to the appropriate .Eraille cell. The 
two entry words for each character contain the Braille code 
and the rules governing the translation. In order to 
accommodate the additional symbols specified by the Nemeth 
Code, this table is expanded to include codes for which 
there is no input character (Braille indicators) and codes 
for which there are two different representations depending 
on context (numerals, certain punctuation marks, etc.) . 

Since input to the Translator is provided by the 
Pre-processor, the codes need not be limited to six bits but 
will use a seventh and eighth bit to provide the additional 
information. 

* 

This expanded code set not only provides additional symbols, 
but also is used to avoid redundancy between the functions 
of the Pre-processor a'nd the Translator. For example, the 
Translator program inserts, two indicators (numeric and 
alphabetic) according to the' rules of English Braille. By 
providing the appropriate eight-bit pseudo code, the 
Pre-processor will cause the Translator to insert these 
indicators according to the rules of Nemeth Code as. well. 

For example, a sequence of numerals may be represented in 
three different forms in a mathematical text: 

'1. Numerals which represent page numbers are preceded 
by the numeric indicator and the Braille codes A-0 
stand for the numerals- 1-0. 

2. Numerals which are mathematical statements within 

the text are preceded by the numeric indicator and 
are represented in Eraille by the LOWER CELL codes 
-f or- -fir-Jv — - -- 

3. Numerals arranged for computation are not preceded 
by the numeric indicator and are represented by the 
LOWER CELL A-J codes. 

The Pre-processor will perform the analysis necessary to 
determine which of these representations is correct and will 
supply the proper one of three possible numeric input codes. 



In the first case, a reference to ’page 13* in the text 
would be interpreted by the Pre-processor which would supply 
the Translator the codes 001, 003. The table entries for 
these codes contain the Braille codes for A and C, and the 
rules entries will cause the insertion of the numeric 
indicator in front of the 1.. 

The same numbers in the sentence » 13 is a prime number* 
would be converted to the pseudo codes 101 and 103. The 
table entries for these codes contain the lower cell Braille 
codes, but the rules would still cause the insertion of the 
numeric indicator. 

Should the sane number appear as follows: 

13 

x2 

26 

the Pie-processor would supply the pseudo codes 201 and 203. 
The Braille codes in these entries would again be the lower 
cell codes, but the rules associated with these entries 
would not cause the Translator to insert the numeric 
indicator. 

The insertion of the alphabetic indicator is handled 
analogously. A reference to ’page 2A’ requires the 
insertion of the alphabetic indicator, but the indicator is 
not required for the statement *2A + 3Brr 13*. The proper 
conversion is accomplished by the use of pseudo codes for 
the letters A-J when they are in contact with lower cell- 
numerals, or when other aspects of the context rule out the 
use of the indicator. 

Symbol Table 

This table contains an entry for each input code produced by 
the keypunch and each entry word is divided into three 
segments, as illustrated beiow: 



AM Description 

/-/-/ / 

SI 3 17 



Subroutine 

/ — / 

21 35 



Bits S and 1 describe whether .the character is alphabetic or 
mathematical. The Sign bit is 0 for alphabetic characters, 
for all others. Bit 1 is 1 for all mathematical 
characters (numerals, operators:, etc.) and 0 for all others. 
Thus, the letter A is coded 00, the number 3, 11 and the 
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comma, 10. (Note: As an input code, the comma is neutral; 

the Pre-processor determines whether it is mathematical or 
literary.) These bits are used to set a switch which 
describes the nature of a word or character stream. The 
bits for each character are combined (using the OS 
instruction) to produce one of three different settings: 



CAT 


o 

o 

* 

O 

o 

L> 


T (00) 


- 00 


All alphabetic 


2A 


2 (11) * A 


(00) . 


= 11 


Some math 
symbol 


AT, 


A (00) * T (00) * 


r (10) 


- 10 


Alphabetic and 



punctuation 



As these bits are defined, no character can be coded .01. 

The final code, or switch setting, determines how that word 
is handled by the Pre- processor . Words which are all 
alphabetic (CO) are looked up in the Word Table. A seguence 
of characters which includes, at least one mathematical 
symbol is scanned to determine whether indicators should be 
inserted or whether input codes should be converted. In the 
case of punctuated alphabetic material, the alphabetic 
portion, must be iso.lated before reference to the Word. T~ble. 

The Decrement, bits 3-17, are used to describe certain 
characteristics of the symbol. These categories are not 
exclusive, and several bits may be used to describe one 
character. For example, a left parenthesis would be 
described as: 



Open grouping symbol, ambiguous punctuation, initial 
punctuation. 

The designation, I.nitial Punctuation, is used to facilitate 
the separation of alphabetic material from associated 
punctuation before referring to the Word Table. The 
Ambiguous Punctuation bit means that the subroutine must 
select one of two codes depending on context. The Open 
Grouping Symbol bit would be used if the mathematical (or 
literary) nature of the enclosed material is not immediately 
obvious. Under certain conditions the program will scan for 

the Final Grouping Symbol in order to select the proper 
code. 

The Address portion of the word, bits 21-35 contain the 
address of the subroutine which will convert the input 
character when necessary, insert indicators or spaces, 
pass it, unchanged, to the Translator. 



or 



Information in this tab,le is arranged so that it can b..e 
retrieved guickly and simply. The descriptive hits -for a 
given character are stored in a location whose address is 
computed hy subtracting the input character bits from the 
Symbol Table Origin. Thus, the indicator bits and 
subroutine address for the number 5 are found in location 
(Table Origin — 5) « The character itself is not stored in 
the table. The code to be output is either retrieved from 
the input stack or supplied by the subroutine. When 
necessary, the input code may be modified before it is 
passed to the Translator. 

Word Table 

- \ 

This table contains the alphabetic codes and associated 
indicator bits for three types of words: 

. 1. Format codes which identify and describe 

information which, is to be arranged .spatially. The 
subroutines which handle these codes will collect 
input until the appropriate terminating code is 
read, will insert spaces and line ending codes 
where necessary, and then pass this material to the 
. Translator. 

2. Abbreviated function names (SIN, COS, etc.). 

These are included in the table so they can be 
identified as mathematical ex-pressions which must 
not be contracted and. which must be punctuated 
appropriately. 

3. TO, INTO, BY, and ARC. The disposition of these 
words cannot be determined until the succeeding 
word is scanned. If tfe second word is 
mathematical, the subroutine will precede the pair 
of words with a signal ($IG1) to the Translator 
that no contractions may be used. 

T*- ■» words in this table are located by means of a sub-table 
ca^ed the Pointer Table. A pointer entry for a given word 
is stored in the location (Pointer Table Origin - N) where N 
is the number produced by performing an EXCLUSIVE OR of ail 
the characters in that word. This entry contains an index 
to the Word Table entry which contains the characters of the 
word. The adjacent entry in the Word Table identifies the 
subroutine which handles the word. Since the number of. 
special words is less than 63 , not all words in the Pointer 
Table will reference the Word Table. (Should future 
additions to the Table exceed this number, a seven-bit N can 
be produced by shifting certain bifs before performing the 
OR.) 



In some cases, two or mere special words may produce the 
same N. For this reason, the Pointer Table entry contains a 
multiple entry code and the index to the first of these 
entries m the Word Table. - - 

The look-up procedure is as follows: 

1. When a word is identified as *all alphabetic* or 
when the alphabetic characters .o.f. a. .p.u.nctuated word 
have been isolated-, -the cha-r-ac-ters of that input 
word are GE-ed. The resultant number is used to 
locate the Pointer Table entry. 

2. If the Pointer Table .word is zero, the input word 
is identified as non— special and. is. -passed 
directly to the -Tr-ansla-t-or-.- 

3. If the Po inter- -wor-d co-n-tai-n-s- a*n index, the Word 
Table entry is compared, character-for-character 
with the input word. If there is a -match, the 
appropriate subroutine is entered by. referrinq to 
the adjacent Table entry. 



If there is no match, and the Pointer word 
indicates that there is only one entry, the incut 
word is passed direct-ly to the Translator. 

5. If there are multiple entries, the succeeding table 
words are compared with the Input word. Since 
these entries are arranged alphabetically, 
additional entries will be examined only if the 
mitral, character of the input word .is higher than 
the last table word examined, if it. is lower, 

there is no possibility of a match among the other 
entries. 



FORM FIRST LINE, GRID 



(D) 



(E) 



1 PLACE ROW LABEL | 
I IN GRID J 



V V 



. > j 

| PLACE COLUMN LABEL- | 
j. IN GRID | 



.V V- 

J . j 

| FETCH INPUT CHAR. | 



V . 

XXXXXXXXXXXXX 
X . X 

X UNDERLINE ? X.. (Y) 

X , X 

XXXXXXXXXXXXX 
• 

(N) 



V 

XXXXXXXXXXXXX 
X X 

X COMMA ? X.. (Y) 

X X 

XXXXXXXXXXXXX 

(N) 

V 

I , 

| STEP X* j 

| j 



*X - ITEM LENGTH 

XMAXC - LONGEST ITEM IN 
GIVEN EXAMPLE 





E. TYPICAL SUBROUTINES 



In the course of processing -keypunched input for the 
Translator, it is frequently necessary to store a stream of 
characters and then to retrieve them for purposes of 
conversion or transmission* The routines which accomplish 
this are used not only by the main program, but also by 
other subroutines. Therefore, they are described here 
first . 

Stack Routines 

A stack is a method of storing information in a list using a 
completely self-contained subroutine,. The unigue guality of 
a stack derives from the routines to store and retrieve 
information from the list. These routines are complete' 
self-contained and the user need not concern himself w < 
the manipulation of index registers or the actual local 
of the stored data. 

Essentially, these routines perform the functions outlined 
below: 

Pointer — Pointer itl 1 
Item ^z^Stack 

Save Pointer 
Return 

A frequent variety of stack uses the » last-in, first-out* 
principle. Information is stored sequentially in the stack 
by placing it in the AC and calling a subroutine (DOWN) . 

DOWN maintains a pointer which shows the last location in 
which significant in.formation has been placed. To retrive 
information, a call is made to another routine (UP) which 
places the word in the AC and modifies the pointer to 

indicate that the next to the last word is now the last 
word. - . 

Another version of a stack uses the. *first-in, first-out* 
principle. The DOWN subroutine works as above, but the UP 
routine retrieves information in the order in which it was 
placed in the, stack-., , N 

These routines are extremely flexible. Switches indicating 
whether the stack is empty or full may be set, and in 
general, any condition of interest can be noted. 

Format Routines 

Although thoro will bG insny Fornidt iroutinGS oiig for Gsch 



of the Format statements - they have in common the function 
of inserting spaces and line-ending codes to produce the 
desired alignment of characters. While some other examples 
are simpler, the XFORM routine is described here x to 
illustrate the problems involved and the techniques used to 
solve them. 

The XFORM routine is designed ,to arrange an array of 
exercises and to supply the appropriate labels for each 



example. An exercise array 


is a 


set of problems arranged 


for computation 


. No answers 


are 


shown. One such array, as 


it would appear 


in inkprint. 


is 


shown below. 




a. 


b 


c 


1 . 


2 


5 


13 




+ 1 


+6 


+ 4 


2. 


4 


17 


9. 




-2 


, -5 


-6 



The Braille rules reguire that the column identification (in 
this case, a, b, or c) be written to the left of each 
example, that a period and a space follow the letter, and 
that the examples be separated by two spaces. If a given 
row cannot be accommodated on one Braille line, it must be 
rearranged appropriately. While this is a time consuming 
task for the editor and the Braillist, it is essentially a 
matter of counting — a problem ideally suited to computer 
handling. 

The keypunch instructions for this and other spatial 
arrangements are designed to minimize the decision-making 
and keystrokes reguired of the operator. (See KEYPUNCH) 

For this particular example, the operator punches an XFORM 
statement describing the array: 

XFORM 2 rows (1. - 2.) 3 cols (a - c) 

Following this, statement, the problem material is punched as 
shown below: 

2,+1// 5, +6// + 4// 4,-2// 17,-5// 9,-6// 

The comma is used to s^arate one number (or operand) from 
another. The symbol // indicates an underline. Because the 
XFORM statement describes the row and column arrangement and 
labels* the operator can punch the exercises sequentially 
without indicating line endings. The XFORM routine will 
arrange the material and supply the labels, adding periods 
where necessary-. 
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As indicated in the accompanying flow charts, there are two 
• phases within the XFOEM routine. The first of these is the 
development o± a grid, or mask, containing the necessary 
spaces and labels. The second is the insertion of the 
exercise material in the appropriate locations. 

A grid is a stack which represents the arrangement required 
for a given row in an array. Since, it is necessary to 
determine the maximum width of a column, the grid for the 
first line of the row can oniy be formed after scanning all 
items in the row. The grid for all succeeding lines is a 
modification of the first one. To illustrate, the grids for 
the sample exercise array would be the following: 

(* denotes a space) 

First line: 1* *a.*00**b. *00**c.*00$EL* 

Other lines: ******00*****00*****00$EL* 

The zeros indicate where the exercise material may be 
inserted in order that the columns be properly separated and 
aligned, and the number of zeros represents the size of the 
largest item in each example. 

During the insertion, or Fill, phase, the exercise material 
J-S scanned backwards, one line at a time. The units 
position number is inserted in the grid first, then the tens 
position, and so on. If a particular item is smaller than 
the space allowed, the routine inserts a space code for each 
remaining zero in the grid. To accomplish this, a grid 
stack item and an input stack item are examined to determine 
what code should be placed in the output stack. The table 
below indicates the output code for each possible condition. 



Grid — 0 Grid ^ 0 



— number 


number 


grid 


item 


— operator 


operator 


grid 


item 


— comma 


space 


grid 


item 


— underline 


space 


grid 


item 



Selecting the input stack item to be examined involves 
skipping through the stack to pick out the factor for a 
given line. As each input item is moved to the output 
stack, a record is kept which causes the routine to ignore 
that item during subsequent scans. 
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?; ni P OI:t ^ nt b -y product of the grid making phase is a count 
of the number of lines required for a given row of the array. 
In general, formatting the Br k aille page is handled by the 

io^ S i at ° r ’ " hen 3 ! , ° r ! Dat routine is entered, the usual 
ord for word, transmission is interrupted, and 

routine reads and arranges a number of lines, 
must be preceded by a signal to the Translator 
how many lines there are. This signal (SARfln) 
he Translator to calculate whether the array 



page currently being assembled, 
be started. 



the Format 
These lines 
indicating 
is used by 
can fit on the 



or whether a new page must 



Not indicated in the general flow chart is the fact that 
this routine supplies the appropriate pseudo-codes for 

letters and numbers which should not be preceded bv 
indicators. 1 



\ 
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XFORM ROUTINE 
GENERAL FLOW CHART 



, , 

| SAVE XFORM STATEMENT) 

J , 



(A) 



V V 



i 1 

| SCAN ONE ROW ) 

| j 

V 

| 1 

| FORM. GRID FOR FIRST LINE | 
, 1 



V 

| | 

) OUTPUT | 
| $ABAn | 

j , 



■V, 



| , 

j SCAN ONE- -L-I-N-E- - -| 

) , 

• •«««••• • 

v V 

• I 1 

j FILL GRID j 
j t 1 



V 

I , 

i OUTPUT I 
) 1 LINE | 

| , 



.. (N) 






V 

xxxxxxxxx 



• • • (■N-) •••• 


-..X . 


X.... 


(Y) - 




V . 


X LAST 


LINE?X 




V . 


| . | 


X 


X 




X XXXXX-XX 


j STEP LINE) 


XXXXXXXXX 




X . X 


1 COUNT j 






(») • 


.X LAST ROW ?X. . (Y) 


1 1 






• 


X . X 


* 






• 


XXXXXXXX 


-V- 






• 


• 


xxxxx.xx 






V 


V 


• X > • 


...(•Y.) 




(A) ■ 


RETURN 


X2ND LINE?X 




V 






X X 


| 


1 






XXXXXXX 


1 FORM 


NEW GRID) 








1 


j 




- 
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U NDE-B-l-I-N-E- 



(B) 

- V- - - . 

xxxxxxxxxxx 

X - X- - - 

• * • ‘W X XMAXC? X.... , 

X X 

XXXX-XX-X-X-X-X-X - 



- - V-- - 



I x XMAXC j 



V 



| PLACE XMAXC -Z-EROS j - 
I IN GRID j. 






, 

I SET X 1 j 



•I— 



“•I* 



V 

xxxxxxxxxxxx 
x * x • 

< N > --X L..XHAX? X (Y, 

X X 

xxxxxxxxxxxx 

v 



I X L.MAX j 



V 

EN-D 0-P- -L-I-N E- - - 
TEST 

* L - NUMBER CF LINES - 
FOR GIVEN EXAMPLE 

LMAX - NUMBER OF LINES, LONGEST EXAMPLE 
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END OF LINE TEST 



I 

* 

{ 

J EM AX 

I 



j 

* I 

GCOUNT = Z | 
| 



V 

xxxxxxxxxxx 

X • X 

..... (N) X Z < 0? X (Y) 

V X X V 

XXXXXXXXXXX XXXXXXXXXXX TRUNCATE LINE 

X X 

<N).X 0<Z<4?‘ ‘ *X.* (Y) 

X ' X 

XXXXXXXXXXX V 

END OF LINE 



■ ' “ ” ' V~~ 

XXXXXXXXXXX ! 

‘X ~~ “ ■ ■ “"X ■" : 

(N).X LAST X (Y) 

. X CGLU KN? * * X ; 

. XXXXXXXXXXX - V 

END OF LINE 

(D) 



* BMX - MAXIMUM LENGT E ERAILLE LINE 
GCOUNT - CURRENT GRID LENGTH 
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COKHA 



(N) 



(C) 



V 

xxxxxxxxxxx 
x x 

. . .. ..X X > XMAXC? X 

x x ' 

xxxxxxxxxxx 




V 

j --- 

J X -£► XMAXC 
| 



V 



j 1 

I SET X = 1 | 

J , 



V 



I STEP LIKE COUNT J 



V 

(E) 



FETCH 

INPUT CHARACTER 
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FILL ROUTINE 
J V. 

| , 

| FETCH GRID j 

1 CHARACTER j 






I 



(N) 



I 



xxxxxxxx 
X x 

* • X = -0 ? X, 
X X 

XXXXXXXX 



(Y) 



1 



| HOVE GRID j 
! CHAR. TO | 
1 OUTPUT j 

j , ~| 



xxxxxxxxx 
x x 

. (N) .X LAST GRID X. (Y) 
X CHAR. ? X 
- XXXXXXXXX 



V 

PUT OUT 
LINE 



j 



(Y) 

V 






I — 

| MOVE J 
j, SPACE TO | 
| OUTPUT } 
, , 



— - I 

! FETCH INPUT J 
| CHARACTER \ 

j 1 



V 

XXXXXXXX 
X COMMA ?X 
.X UNDER- X. (N) 
X LINE ? X 
. XXXXXXXX 

V 

I- -=•- 

I MOVE 



V. 

-I 



|-“ I 

| FETCH GRID J- 

1 CHARACTER j 
A 

I , 

xxxx 

X X 

(N) X= 0 ? X ( Y) 
X X 

. XXXX 



| INPUT CHAR 

| TO OUTPUT 
• * 

| 



| ^ — 

1 SKIP INPUT 
1 POINTER TO 
1 NEXT ITEM, 

| THIS LINE 
j 



